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Abstract 

The  Army  Operational  Architecture  (AO A)  Program  provides  the  framework  and  integrates  the 
operational  architecture  development  efforts  within  the  Army.  OA  is  an  integral  part  of  the 
Army  Enterprise  Architecture  (AEA)  and  is  one  of  three  architecture  views,  the  others  are 
System  and  Technical  architecture.  TPIO-ABCS  is  the  Executive  Agent  for  the  Army’s  entire 
Operational  Architecture  (OA)  and  is  responsible  for  the  development,  management,  and  over¬ 
site  of  all  OA  products.  An  extensive  OA  Configuration  Management  system  has  been 
established  to  ensure  all  protocols,  standards,  validation  and  approved  procedures  are  in 
compliance.  The  Army  OA  Program  is  a  function  and  responsibility  of  DCSOPS,  DA  and  is  an 
integral  part  of  the  Army  Enterprise  Architecture  (AEA).  This  document  is  designed  to 
enlighten  the  overall  architecture  community  on  the  current  status  of  the  Army  OA  program.  The 
AOA  is  a  disciplined  approach  to  the  Requirements  Determination  Process  and  provides  synergy 
and  coordination  enablers  for  the  Combat  Developments  arena  that  meet  the  Warfighter 
requirements.  Operational  Architecture  is  the  catalyst  to  re-engineering  the  Army.  OA  is  a 
disciplined  and  systematic  process  used  to  identify  and  generate  requirements  for  Doctrine, 
Training,  Leader  Development,  Organization,  Materiel,  and  Soldier  Support  (DTLOMS)  domain 
incorporation.  OA,  as  a  combat  development  function,  represents  a  dramatic  change  in  thinking 
about  requirement  determination  and  generation.  Given  the  unprecedented  complexity  of  the 
digitized  battlefield  and  the  current  austere  resource  environment,  forming  vague  battle 
command  information  requirements  in  generic  detail  will  not  do.  OA  is  the  combat  development 
process  capable  of  accurately  identifying  force  information  requirements  in  sufficient  enough 
detail  to  properly  illuminate  the  investment  decisions  that  must  be  made  to  move  the  Army 
forward.  OA  is  focused  on  Warfighter  functions,  information  requirements,  and  performance 
parameters  necessary  to  accomplish  the  mission. 
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EXECUTIVE  SUMMARY 


INTRODUCTION. 

The  Army  Operational  Architecture  (AO A)  program  provides  the  framework  and  integration  for 
the  operational  architecture  development  efforts  within  the  Army.  This  document  provides  an 
outline  for  the  direction  development,  management,  and  use  of  the  Army’s  operational 
architecture.  The  AOA  Program  prescribes  how  to  meet  the  directives  of  the  Army  Enterprise 
Architecture  (AEA)  Master  Plan  and  AEA  Guidance  Document  (Draft).  The  Army  Science 
Board  (ASB)  introduced  the  architecting  approach  to  information  system  development  and 
acquisition  to  the  Army  in  the  Fall  of  1994.  Director  of  Information  Systems  for  Command, 
Control,  Communication,  and  Computers  (DISC4)  and  the  Army  Digitization  Office  are 
implementing  it  at  the  Department  of  the  Army  level.  The  architecting  approach  recommended 
by  the  ASB  included  development  of  three  types  of  architectures  -  Operational,  Systems  and 
Technical. 

The  AOA  Program  fulfills  the  Clinger-Cohen  Act  requirement  to  develop  an  enterprise- wide  IT 
architecture. 

Purpose. 

The  principal  purpose  of  the  AOA  Program  is  to  prescribe  the  processes  for  developing, 
managing,  and  using  the  Army’s  operational  architecture — the  AOA.  The  AOA  Program 
provides  an  Army-wide  planning  directive  that  establishes  the  AOA  vision,  goals,  objectives  and 
strategy.  TPIO-ABCS  implements  processes  that  synchronizes  and  integrates  OA  products.  OA 
is  the  cornerstone  for  system  development  and  DTLOMS  improvements.  It  is  the  Warfighters’ 
responsibility  to  clearly  define  functional  and  informational  requirements,  and  performance 
parameters  needed  to  support  the  battlefield  mission.  The  AOA  provides  a  structured  process 
that  promotes  product  reuse  and  synchronization,  and  promotes  interoperability. 

This  document  supports  the  development  of  operational  architectures  to  support  the  warfighters’ 
operational  requirements.  It  also  prescribes  a  performance-based  process  for  evaluating  the 
AOA.  The  AOA  Program  promotes  a  coordinated  approach  to  developing  the  AOA  and  a 
synchronized  approach  to  AOA  planning.  It  also  outlines  what  comprises  an  operational 
architecture,  the  products  involved,  and  the  procedures  for  configuration  management. 

Scope. 

The  scope  of  the  AOA  Program  focuses  on  the  agencies  involved  with  the  AOA  and  the 
procedures  to  follow  in  developing  an  OA.  The  scope  includes: 

•  All  AOA  development  activities 

•  The  management  and  use  of  the  AOA 

•  The  development  of  operational  architectures  and  configurations  control  measures 

•  The  operational  architecture  validation  process  and  requirements 


STRATEGY. 

The  AOA  Program  strategy  provides  the  context  for  the  development,  management,  and  use  of 
the  AOA  and  relates  the  AOA  to  the  Warfighters’  information  technology  (IT)  requirements.  It 
describes  a  process  that  begins  with  strategic  planning  and  includes  program  planning,  execution, 
and  performance  measurement. 

ORGANIZATION. 

The  AOA  Program  identifies  the  Army  organizations  that  play  roles  in  the  development, 
management,  and  use  of  the  AOA,  and  specifies  responsibilities  among  those  organizations.  In 
addition,  the  AOA  Program  describes  the  strategy  for  building  the  AOA,  using  a  requirements- 
based  approach.  The  strategy  establishes  the  initial  priorities  for  AOA  development  and 
provides  guidance  concerning  the  establishment  and  use  of  performance  measures. 

The  AOA  Program  supports  the  development  of  operational  architectures  for  the  Warfighters’ 
operational  requirements.  It  also  prescribes  an  objective-based  process  for  allocating  AOA 
development  resources  and  a  performance-based  process  for  evaluating  the  AOA.  The  AOA 
Program  promotes  a  coordinated  approach  to  developing  the  AOA  and  a  synchronized  approach 
to  AOA  planning. 

We  are  engaged  in  building  an  Army  for  the  21st  Century — an  Army  that  can  dominate  the  land 
battles  in  joint  and  combined  operations,  across  the  spectrum  of  conflict,  by  gaining,  controlling, 
and  exploiting  information.  Force  XXI  and  the  Army  After  Next  show  an  Army  evolving  to  and 
beyond  the  dominant,  information-age  land  force  described  in  Joint  Vision  2010  and  Army  Vision 
2010.  One  of  our  challenges  is  to  build  the  21st  Century  Army  by  applying  limited  resources — 
people,  time,  and  money — effectively  and  efficiently. 

The  ability  to  transmit,  receive,  display,  process,  manage,  and  use  accurate  and  timely  battlefield 
information,  in  the  context  of  shared  situational  awareness,  is  the  key  building  block  of  the 
information- age  Army.  Efforts  to  build  the  information- age  Army,  therefore,  must  focus  on 
developing  and  fielding  forces  that  possess  the  capabilities  to  gain  and  exploit  information 
dominance. 

The  1993  Army  Enterprise  Strategy  directed  the  development  of  operational,  systems,  and 
technical  architectures  to  describe  Warfighters’  information  requirements  and  Army  C4I  systems 
that  support  the  Warfighter.  Separate  efforts  to  develop  and  produce  each  of  these  architectures 
are  well  underway.  Since  the  publication  of  the  Army  Enterprise  Strategy,  the  Chairman  of  the 
Joint  Chiefs  of  Staff  published  Joint  Vision  2010,  the  Chief  of  Staff  of  the  Army  (CSA) 
published  Army  Vision  2010,  both  directing  that  the  AEA  process  be  followed.  Congress  passed 
the  Clinger-Cohen  Act  of  1996,  mandating  the  architecture  (OA,  SA,  and  TA)  is  developed  to 
meet  future  IT  requirements  and  digitization. 

The  Army  Enterprise  and  the  Army  Enterprise  Architecture. 

The  Army  Enterprise  is  the  entire  Army,  including  all  major  commands,  headquarters,  agencies, 
installations,  and  Army  forces.  The  Army  Enterprise  represents  the  Army  as  a  corporate  entity 
and  prescribes  a  new  way  of  accomplishing  the  Army’s  missions  by  taking  full  advantage  of  IT, 


using  innovative  business  practices,  and  synchronizing  Army  IT  resource  management  activities 
toward  common  goals. 

The  Army  Enterprise  Architecture  (AEA)  fulfills  the  Clinger-Cohen  Act  requirement  to  develop 
an  enterprise- wide  IT  architecture  across  the  command,  control,  communications,  computers, 
intelligence,  surveillance,  and  reconnaissance  (C4ISR)  spectrum.  The  AEA  is  an  Army-wide  IT 
architecture  that  describes  the  relationships  among  key  Army  institutional  processes  and  IT  to 
ensure:  1)  the  alignment  of  the  requirements  for  information  systems  with  the  processes  that 
support  the  Army’s  missions;  2)  adequate  Army,  joint,  and  combined  interoperability;  and  3)  the 
application  and  maintenance  of  a  set  of  standards  (including  technical  standards)  by  which  the 
Army  evaluates  and  acquires  new  systems. 

Some  key  points  of  interest  on  why  there  is  an  AEA  are  depicted  in  Figure  1. 


Why  an  Enterprise  Architecture 


Contributes  to  Warfighter  Capability 

-  Essential  for  the  level  of  interoperability  to  gain  Information  Dominance 

-  Enabler  for  achievement  of  fast  and  accurate  information  flows 

Provides  a  Disciplined  Approach  to: 

-  Link  military  strategy  and  doctrine  to  the  employment  of  technology 
used  in  executing  military  operations 

-  Develop  an  investment  strategy 

-  Manage  C4ISR  complexity 

•  It’s  the  Law 

-  Fulfills  the  Clinger-Cohen  Act  requirement  to  develop  an  enterprise-wide 
IT  architecture 


TRADOC:  WHERE  TOMORROWS  VICTORIES  BEGIN 


Figure  1.  Why  an  Enterprise  Architecture 

The  AEA  takes  a  system  of  systems  approach  to  transforming  the  Army’s  operational  patterns 
into  warfighting  “capability  packages.”  This  approach  takes  full  advantage  of  and  promotes 
horizontal  information  technology  insertion  and  cuts  across  “functional  stovepipes”  and  Service 
boundaries. 

The  AEA  is  comprised  of  the  AOA,  the  Army  Systems  Architecture  (ASA),  and  the  Joint 
Technical  Architecture-Army  (JTA-A).  The  AEA  roles  and  relationships  for  OA,  SA,  and  TA, 
and  the  agency  responsibilities  are  depicted  in  Figure  2. 


Roles  and  Responsibilities 


Enterprise  Synchronizer  -  ODCSOPS  (ADO) 
Architecture  Synchronizer  -  ODISC4 
Enterprise  Task  Lead  -  ODISC4 
Executor  -  Council  of  Colonels 
EGOSC  -  (1  star  level) 

EBOD  -  (3  star  level) 


Synchronization 


Joint  Technical 
Architecture-Army 
(JTA-A) 


Responsibility  -  SARD/AAE 
DA  Staff  lead -ODISC4 
Enterprise  Task  lead  -  ODISC4 
Executor  -  ODISC4/AMC/CECOM/ 


ASEO  Migration-ADO 


Figure  2.  AEA  Roles  and  Relationships 


Army  Operational  Architecture. 

The  AOA  provides  a  disciplined  and  systematic  process  to  identify  the  warfighters'  functions, 
information  requirements,  and  performance  parameters.  AOA  is  a  valuable  source  for  DTLOMS 
assessments.  OA  precisely  identifies  the  functions  performed  within  command  systems, 
associated  data  elements,  and  their  flows.  This  process  provides  the  information  requirements 
and  means  required  to  assess  trade-offs  and  value  added  by  various  possible  changes  in  existing 
or  planned  systems.  OA  provides  the  functional  requirement  that  enables  the  system  architect  to 
build  the  appropriate  battle  command  system.  OA  provides  systems  and  technical  architects  with 
the  specific  information  they  need  to  optimize  their  functions.  OA  facilitates  intelligent 
information  system  decision-making  at  the  very  earliest  stages  of  requirement  determination;  as 
such,  it  is  producing  a  revolution  in  the  way  battle  command  system  combat  developments  are 
accomplished. 

Army  Systems  Architecture  (ASA). 

A  description,  including  graphics,  of  the  systems  and  interconnections  providing  for  or 
supporting  a  warfighting  function.  ASA  defines  the  physical  connection,  location,  and 
identification  of  key  nodes,  circuits,  networks,  warfighting  platforms,  etc.,  and  allocates  system 
and  component  performance  parameters.  System  architecture  is  constructed  to  satisfy  an  OA  per 
standards  defined  in  the  governing  technical  architecture.  The  OA  is  a  critical  element  for  the 
SA  developments,  as  the  OA  provides  the  SA  with  the  warfighter  functions,  information 
requirements,  and  performance  measures.  ASA  shows  how  multiple  systems  within  a  domain  or 
operational  scenario  link  and  interoperate,  and  may  describe  the  internal  construction  or 
operations  of  particular  SA  systems.  The  Office  of  the  Director  for  Information  Systems 


Command,  Control,  Communications,  and  Computers  (ODISC4)  is  the  executive  agent 
responsible  for  ASA. 

Joint  Technical  Architecture- Army  (JTA-A). 

The  minimal  set  of  rules  governing  the  arrangement,  interaction,  and  interdependence  of  the 
parts  or  elements  of  a  system  to  ensure  that  a  system  satisfies  a  specified  set  of  requirements. 
JTA-A  identifies  services,  interfaces,  standards,  and  their  relationships.  It  provides  the  technical 
guidelines  for  implementation  of  systems  upon  which  engineering  specifications  are  based, 
common  building  blocks  are  built,  and  product  lines  are  developed.  JTA-A  provides  the 
parameters  for  the  ASA  in  its  development  of  the  SA.  DISC4  is  the  executive  agent  responsible 
for  JTA-A. 

Figure  3  depicts  Operational  Architecture  and  gives  a  definition  of  the  three  architectural  views 
within  the  Army  Enterprise  Architecture. 


Operational  Architecture  Defined 


A  description  (often  graphical)  of  the  operational 
elements,  assigned  tasks,  and  information 
flows  required  to  accomplish  or  support  a 

Warfighting  Function. 

It  defines  the  type  of  information,  the  frequency 
of  exchange,  and  the  tasks  supported  by  these 
information  changes. 


Operatic  nal 

k  •Operational  Arch 

1  Architec  ure  1 

M  aggregation  of  n 

ions,  functions,  tasks,  * -> 
information  requirements,  and  business  rules 

• System  Architecture  (S.  1 )  is  the  physical 
implementation  of  the  OA,  the  layout  and 
relationship  of  systems  and  communications 

•Technical  Architecture  (TA)  is  the  “building 
codes”  upon  which  systems  are  based 


ft: 


TRADOC:  WHERE  TOMORROW’S  VICTORIES  BEGIN 


Figure  3.  Operational  Architecture  Defined 


AQA  Vision. 

The  following  vision  of  the  future  describes  the  desired  end-state  of  AOA  development 
activities:  An  Army  Operational  Architecture  that  is  warfighter  based  to  build  a  comprehensive 
and  dynamic  Army-wide  IT  architecture,  that  is  founded  in  DTLOMS  analysis  and  Business 
Process  Re-engineering.  The  AOA  will  enable  the  21st  Century  Army  to  gain  and  exploit 
information  dominance  which  enables  the  warfighter  to  more  efficiently  conduct  military 
operations  in  Army,  joint,  and  combined  environments. 


AOA  Goals. 

Provide  accurate  and  timely  analysis  of  alternatives  to  support  the  Army  decision  making 
process  to  impact  the  C4ISR  systems. 

Enable  stronger  Army,  joint,  and  combined  interoperability  and  flexibility  that  enhances  the 
warfighter’s  capabilities  to  efficiently  conduct  military  operations. 

Integrate  and  synchronize  OA  analyses  that  support  warfighters’  planning  and  operational 
needs  through  the  DTLOMS  domains. 

Provide  valid  OA  analysis  that  provides  the  SA  and  TA  communities  the  foundation  for 
developing  and  fielding  integrated  systems  with  the  capabilities  that  meet  Army  warfighting 
requirements. 

AOA  Objectives. 

The  AOA  program  objectives  support  achieving  a  specified  end-state  and  describe  specific 
measurable  states  to  be  accomplished  for  the  Warfighter.  The  AOA  objectives  are  derived  from, 
and  support,  achieving  the  AOA  goals  and  vision.  The  objectives  are: 

An  operational  architecture  that  represents  the  IT  requirements  for  the  Division  XXI  (This 
objective  supports  the  Chief  of  Staff’s  digitization  and  interoperability  goals  for  Division  XXI 
for  2000.) 

An  operational  architecture  that  represents  the  IT  requirements  for  the  Corps  XXI  (This 
objective  supports  the  Chief  of  Staff’s  digitization  and  interoperability  goals  for  Corps  XXI  for 
2004.) 

An  operational  architecture  that  represents  the  IT  requirements  for  Army  XXI  (This  objective 
supports  the  Chief  of  Staff’s  digitization  and  interoperability  goals  for  Army  XXI  for  2006.) 

A  seamless,  joint,  interoperable  IT  architecture  that  increases  Army  readiness,  enhances  the 
warfighting  capabilities  of  Army  forces,  promotes  the  effective  and  efficient  allocation  of 
architecture  development  resources,  and  sets  the  stage  for  building  the  Army  After  Next 

In  addition  to  supporting  the  AOA  vision  and  goals,  achieving  the  objectives  can  produce  a 
variety  of  related  benefits.  By  requiring  the  OA  analysis,  a  disciplined  and  systemic  process  is 
used  to  identify  battle  command  functions,  information  exchange  requirements  (IERs),  and 
performance  parameters.  Precisely  identifying  the  functions  performed  within  an  organization, 
and  the  information  requirements  to  perform  the  functions,  provides  a  disciplined  requirements 
based  approach  analysis  to  the  SA  and  TA  communities  and  becomes  the  basis  for  Army  force 
modernization  efforts  and  the  requirements  determination  process. 


AQA  Roles  and  Responsibilities. 


Commanding  General  (CO-  Training  and  Doctrine  Command  (TRADOC).  The  CG, 

TRADOC  is  the  Architect  for  the  Army.  TRADOC  centers,  schools,  battle  labs,  TRADOC 
systems  managers,  and  the  TRADOC  staff  support  the  CG,  TRADOC  in  the  development  of 
operational  architectures.  CG,  TRADOC  approves  all  Army  requirements  and  oversees  the 
development  of  Mission  Needs  Statements  (MNSs)  and  Operational  Requirements  Documents 
(ORDs)  that  describe  requirements.  As  the  Operational  Architect  for  the  Army,  CG,  TRADOC 
directs  the  development  of  the  Army  Operational  Architecture  and  all  supporting  operational 
architectures.  Specific  CG,  TRADOC  responsibilities  relating  to  the  AOA  are  shown  below. 

•  Coordinate  with  DCSOPS  and  DISC4  to  establish  AOA  program  priorities  and  funding. 
Oversee  the  development  and  management  of  AOA. 

•  Incorporate  AOA  into  the  Requirements  Determination  Process  and  into  TRADOC 

•  PAM  71-9  (Lead). 

•  Coordinate  and  synchronize  with  DISC4  to  ensure  OA  priorities  support  SA  priorities. 

•  Support  the  establishment  and  implementation  of  AOA  rules,  procedures,  and 

•  guidelines. 

•  Provide  information  to  support  AOA  development  planning  and  programming. 

•  Support  requirement  determination  and  validation  (Lead)  through  the  AOA. 

•  Support  the  establishment  of  AOA  performance  measures. 

•  Measure  AOA  performance,  as  required. 

•  Participate  in  the  process  of  using  the  AOA  to  support  battlefield  process  reengineering. 

Commander  (CDR),  Combined  Arms  Center  (CAC). 

The  CG,  TRADOC  has  delegated  the  role  of  the  Operational  Architect  for  the  Army  to  the  CDR, 
CAC.  The  CDR,  CAC  directs  the  synchronization  between  TRADOC  Program  Integration 
Office-Army  Battle  Command  System  (TPIO-ABCS),  the  TRADOC  schools  and  centers,  and 
the  warfighter  concerning  the  development  of  the  AOA  and  OA  products.  Specific  CDR,  CAC 
AOA  responsibilities  are: 

•  Coordinate  with  Headquarters  (HQ)  TRADOC,  DCSOPS,  and  DISC4  to  establish  AOA 
program  priorities  and  funding. 

•  Oversee  the  development  and  management  of  AOA. 

•  Incorporate  AOA  into  the  Requirements  Determination  Process  and  into  TRADOC 
PAM  71-9. 

•  Coordinate  and  synchronize  with  HQ  TRADOC,  DISC4,  and  the  TRADOC  Signal 
Center  to  ensure  OA  priorities  support  SA  priorities. 

•  Oversee  the  development  of  OA  products  through  TPIO-ABCS  and  the  TRADOC 
schools  and  centers. 

•  Support  the  establishment  and  implementation  of  AOA  rules,  procedures,  and 
guidelines. 

•  Provide  information  to  support  AOA  development  planning  and  programming. 

•  Support  requirement  determination  and  validation  (Lead)  through  the  AOA. 

•  Support  the  establishment  of  AOA  performance  measures. 


•  Measure  AOA  performance,  as  required. 

•  Participate  in  the  process  of  using  the  AOA  to  support  battlefield  process  reengineering. 

TRADOC  Program  Integration  Office  -  Army  Battle  Command  Systems  (TPIO-ABCS). 

TPIO-ABCS  is  the  Army’s  executive  agent  for  the  AOA.  TPIO-ABCS  is  responsible  for  the 
development,  management,  and  implementation  of  the  AOA.  The  AOA  program  execution 
authority  is  delegated  to  TPIO-ABCS.  Specific  TPIO-ABCS  AOA  responsibilities  are: 

•  Develop  objective  operational  architectures  for  Division,  Corps,  EAC  and  Army  XXI 
for  all  BOSs  (Lead). 

•Coordinate  recommendations  for  AOA  program  priorities,  funding,  and  development 
with  HQ  TRADOC,  the  DISC4,  and  the  TRADOC  Signal  Center. 

•Develop  seamless,  joint,  interoperable  operational  architectures  (Lead). 

•Develop  and  manage  the  AOA  (Lead). 

•Establish  AOA  rules,  procedures,  and  guidelines  (Lead). 

•Synchronize  AOA  priorities  and  activities  with  HQ  TRADOC  and  the  TRADOC  schools 
and  centers. 

•Develop  and  provide  operational  architectural  solutions  to  warfighters’  operational  and 
planning  requirements  (including,  but  not  limited  to  operational  architectures  that  support 
MNSs  and  ORDs)  (Lead). 

•Use  the  AOA  to  support  requirement  determination  and  validation. 

•Establish  AOA  performance  measures  (Lead). 

•Use  AOA  to  support  battlefield  process  reengineering. 

•Develop  operational  architecture  validation  and  configuration  control  measures  (Lead). 
•Establish  and  maintain  the  AOA  repository. 

•Provide  information,  architecture  models  and  products,  and  other  data  for  inclusion  in  the 
AEA  repository. 

•Maintain  and  update  the  AOA  Implementation  Plan  as  required  (Lead). 

•Direct,  chair,  and  facilitate  the  Configuration  Control  Board  (Lead). 

•Conduct  dynamic  modeling  and  simulations  in  support  of  analyses  and  business  process 
re-engineering  efforts. 

TRADOC  Proponent  Centers  and  Schools. 

The  TRADOC  proponent  centers  and  schools  have  a  major  role  in  the  development  of  OA 
projects.  They  develop  their  own  proponent  OA  initiatives  and  support  the  TPIO-ABCS  OA 
program.  Proponents  will  follow  the  performance  measures  and  the  OA  project  process.  Specific 
TRADOC  centers  and  schools  responsibilities  relating  to  the  AOA  are: 

Develop  operational  architecture  solutions  (models  and 
products)  in  support  of  proponent  initiatives  and  respective 
battlefield  functional  areas,  following  the  procedures 
provided  by  the  AOA  Program. 

Support  TPIO-ABCS  in  the  development  of  an  overarching  OA  that  integrates  the  proponent 
functional  area  OAs  into  a  seamless,  joint,  and  interoperable  operational  architecture. 


Follow  the  AO  A  Program  performance  measures. 

Provide  input  to  support  the  establishment  of  AOA  rules,  procedures,  and  guidelines. 

Use  the  AOA  to  support  requirement  determination  and  validation. 

Use  OA  to  support  battlefield  process  re-engineering. 

Provide  information,  architecture  models  and  products  to  TPIO-ABCS  for  inclusion  in  the 
AOA  repository. 

TRADOC  Signal  Center  (SIGCEN). 

The  SIGCEN  is  responsible  for  the  conceptual  development  of  the  SA  and  the  Command, 
Control,  Communications,  and  Computers  Requirements  Definition  Program  (C4RDP).  In 
addition  to  TRADOC  proponent  center  and  school  responsibilities,  specific  SIGCEN 
responsibilities  relating  to  the  AOA  are  shown  below. 

Develop  and  coordinate  conceptual  SA  requirements  with  TPIO-ABCS  and  DISC4. 

Integrate  configuration  controlled  OA  structures  approved  by  the  TPIO-ABCS  into  the 
C4RDP. 

Integrate  functional  and  informational  requirements  produced  by  a  TPIO-ABCS  approved 
OA  into  the  C4RDP. 

TRADOC  Battle  Laboratories  (BLs). 

The  TRADOC  BLs  have  a  major  role  in  the  supporting  the  development  of  OA  projects,  by 
including  OA  as  a  basis  for  futuristic  initiatives.  Specific  TRADOC  BL  responsibilities  relating 
to  the  AOA  are. 

Incorporate  OA  into  battlefield  process  reengineering. 

Develop  operational  architecture  solutions  (models  and  products)  in  support  of  BL 
initiatives,  following  the  AOA  Program  procedures. 

Provide  information,  architecture  models  and  products  to  TPIO-ABCS  for  inclusion  in  the 
AOA  repository. 

TRADOC  System  Managers  (TSMs). 

The  TSMs  have  a  major  role  in  supporting  the  development  of  OA  projects,  by  providing 
generated  user  requirements  for  their  respective  systems.  Specific  TSMs  responsibilities  relating 
to  the  AOA  are. 


Incorporate  OA  into  battlefield  process  reengineering. 


Evaluate  OA  products  for  accuracy  and  provide  TPIO-ABCS  technical  comments  to  keep 
AOA  products  updated. 

Develop  operational  architecture  solutions  (models  and  products)  in  support  of  TSM 
initiatives,  following  the  procedures  in  this  Implementation  Plan. 

Use  the  AOA  to  support  requirement  determination  and  validation. 

Provide  information,  architecture  models  and  products  to  TPIO-ABCS  for  inclusion  in  the 
AOA  repository. 

AOA  Process. 

The  process  under  which  operational  architectures  are  developed  is  supportive  of  the  Army’s 
combat  development  activities  and  is  founded  upon  the  requirements  identified  within  this 
document.  This  process  ensures  the  Army  is  building  and  fielding  capabilities  which  support  the 
warfighter,  represent  the  optimum  value  added,  and  provides  the  analytic  basis  for  sound 
decisions  concerning  reengineering  opportunities  across  the  DTLOMS  domains  and  realistic 
assessments  of  return  on  investments.  The  OA  process,  and  resultant  operational  architecture 
development,  is  executed  along  two  axes  simultaneously  (standards-based  and  capabilities-based 
axes).  OA  policy  and  guidance  serve  as  control  measures  that  guide  efforts  along  both  axes. 
Warfighters’  visions  and  concepts  that  lead  to  requirements  are  the  starting  points,  or  foundation, 
of  the  process. 

The  standards-based  axis  includes  compliance  with  and  application  of  the  Joint  Technical 
Architecture-Army  (JTA-A).  Compliance  with  the  applicable  JTA-A  standards  will  enable 
Army  forces  to  be  interoperable  and  flexible.  Application  of  the  JTA-A  involves  the  use  of 
common  operating  systems,  common  software,  data  standardization,  data  definition 
standardization,  development  and  adherence  to  a  common  data  element  dictionary,  and  software 
reuse.  The  application  of  and  adherence  to  these  standards  and  principles  will  ensure  systems 
compatibility  and  interoperability  when  fielded  and  support  the  seamless  exchange  of 
information  throughout  the  Army,  in  the  joint  environment,  and  with  our  allies. 

The  capabilities-based  axis  involves  supporting  the  development  of  objective  Information 
Technologies  (ITs)  capabilities  through  architecture  development  efforts.  These  efforts  may  be 
focused  toward  the  development  and  enhancement  of  specific  capabilities — situational 
awareness,  battlefield  visualization,  information  operations,  cooperative  engagement,  etc.;  or 
toward  specific  Army  organizations — Division  XXI,  Corps  XXI,  Army  XXI,  and  the  Army  After 
Next  (AAN).  The  main  focus  on  the  capabilities-based  axis  is  the  development  of  objective  IT 
architectures  for  Division,  Corps,  and  Army  XXI.  Division,  Corps,  and  Army  XXI  represent 
capabilities  and  the  operational  architectures  describe  those  capabilities.  In  that  context,  the 
representative  IT  architectures  are  capability  configurations. 

The  primary  purpose  of  the  OA  is  to  define  the  requirements  (functions)  and  IERs  with  in  the 
desired  mission  area.  The  process  of  developing  the  OA  is  analytical  and  can  be  used  to  develop 
an  OA  at  any  level  of  an  organization  or  combinations  of  organizations.  The  process  uses  five 
phases,  each  with  multiple  steps.  Identify  the  requirement  to  perform  an  OA. 


Form  an  OA  project  team. 

Conduct  a  front-end  analysis. 

This  includes  an  environmental  assessment,  determination  of  the  purpose,  scope,  and  context  of 
the  OA  and  any  that  changes  or  requires  an  OA.  Functions,  information  requirements  and 
performance  parameters  have  changed  (been  merged,  deleted  or  are  new).  Unit  mission  has  been 
changed  or  modified.  A  DTLOMS  domain  has  been  changed  or  modified.  Joint  or  Coalition 
functions  or  mission  have  changed 


Determine  the  Purpose  of  the  OA. 

The  purpose  provides  the  background  of  the  organization,  and  explains  the  necessity  for 
developing  an  OA.  The  purpose  also  explains  what  the  OA  will  accomplish  and  how  it  may 
affect  the  organization  or  how  it  may  affect  system  development. 

Determine  the  Scope  of  the  OA. 

The  scope  of  the  OA  is  a  clear  identification  of  the  architecture  in  terms  of  type  of  architecture, 
subject  area,  temporal  nature,  and  intended  users. 

Validate  the  Context  of  the  OA. 

Validation  is  a  critical  step  in  the  process  of  developing  the  OA.  Validation  of  the  context  is 
necessary  to  ensure  that  development  and  ultimate  implementation  of  the  OA  proceed  according 
to  the  plans  and  intent  of  management.  The  following  sub-steps  apply:  Confirmation.  The  staff 
must  confirm  that  the  scope,  purpose,  and  context  are  correct.  Once  the  context  is  established,  it 
should  be  reviewed  by  the  Commander  and  disseminated  to  staff  members  who  provide  input  or 
are  affected  for  confirmation  and  comment.  This  procedure  ensures  everyone  starts  from  a 
common  perspective  and  serves  as  a  double  check  that  the  context  is  complete  and  well  defined. 
Approval.  The  Commander  must  accept  the  scope,  purpose,  and  context  as  the  correct  start  of 
the  OA  development  process.  Once  the  context  is  confirmed,  the  Commander  approves,  rejects, 
or  modifies  it.  The  OA  project  team  modifies  it  as  required  until  approved.  Decision.  Once  the 
stated  scope,  purpose,  and  context  are  approved,  a  decision  to  accept  and  proceed  with  the 
remainder  of  the  OA  development  must  be  made.  Only  when  the  context  is  accepted  and 
approved  does  the  Commander  decide  to  move  on  to  the  next  step. 

In  general,  the  OA  should  present  the  following  information: 

Missions  to  be  accomplished. 

Operational  elements  to  whom  the  missions  are  assigned. 

Nodes,  geographic  or  functional  locations,  where  the  operational  elements  are  located. 

Functions,  tasks,  and  activities  that  the  operational  elements  perform. 


Information  flows  required  to  perform  the  tasks. 


The  purpose  of  developing  the  OA  is  to  identify  the  functions,  information  requirements,  and 
performance  parameters,  then  apply  business  process  reengineering  methodologies  and  analyses 
to  assess  the  impact  across  the  DTLOMS  domains,  refer  to  Figure  5. 
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Figure  4.  Purpose  of  developing  the  OA 


OA  Life  Cycle. 

The  AOA  Life  Cycle  is  a  living  development  cycle  within  itself  in  defining  and  describing  the 
warfighter  requirements.  The  cycle  is  an  evolutionary  process  that  incorporates  a  cradle  to  grave 
approach  in  developing  the  warfighter  requirements.  The  four  phases  consist  of  conceptual, 
developmental,  verification  and  validation,  and  fielding. 

Conceptual  Phase.  It  begins  with  the  initial  definition  of  the  functional  requirements  as  defined 
by  the  warfighter.  Interviews  and  analysis  are  conducted  with  the  warfighter  to  determine  the 
functional  tasks  and  activities,  information  requirements,  and  performance  parameters. 


Developmental  Phase.  Activity  models,  node  trees  and  context  diagrams  document  the 
requirements  as  defined  from  the  initial  interviews.  From  these  products  are  generated  the  data 
models  that  define  the  informational  exchange  requirements  for  the  warfighter. 

Verification  and  Validation  Phase.  Once  the  products  are  developed,  they  are  verified  and 
validated  by  the  TRADOC  TPIO-ABCS,  schools,  centers,  and  the  Warfighter  community. 
Changes  to  the  baseline  OA  products  are  controlled,  authorized,  and  executed  by  the 
Configuration  Control  Board  (CCB).  Products  will  be  verified  to  ensure  they  conform  to 
applicable  Government  standards,  plans,  and  doctrine. 

Fielding  Phase.  Verified  and  validated  products  will  be  distributed  or  fielded  to  the  applicable 
TRADOC  organization,  schools,  centers,  SA  and  Materiel  Developer  for  implementation.  The 
SA  and  Materiel  Developer  will  work  with  TPIO-ABCS  OA  staff  regarding  any  anomalies,  risk 
factors,  schedules,  and  required  resources.  Any  detected  anomalies  will  be  documented  and 
reported  back  to  the  TPIO-ABCS  for  investigation.  TPIO-ABCS  will  post  approved  OA 
products  on  the  TPIO-ABCS  OA  home  page  (http://leav-www.army.mil/oa/). 


AEAGD/AOA  Support  to  DTLOMS 
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Figure  5. 

The  operational  architecture  is  a  view  of  the  functions  performed  across  the  battlespace 
(physical  and  logical).  An  OA  is  completed  to  allow  and  support  the  development  of  re¬ 
engineering  recommendations  relative  to  the  DTLOMS  domains.  Figure  5,  provides  some 
examples  of  OA  product  impact  on  different  DTLOMS  domains.  It  is  the  baseline  for  the 
identification  of  new  C3I  requirements  and  requirements  generation  for  each  functional  area  and 


serves  to  facilitate  the  development  of  new  concepts.  Development  of  operational  architectures 
also  allows  the  Army  leadership  to  better  understand  the  impact  of  changes  throughout  the  force 
as  they  relate  to  the  DTLOMS.  The  development  of  operational  architectures  also  provides  the 
mechanism  and  process  to  identify  new  IERs;  information  exchanges  requirements,  and 
associated  information  elements  for  the  force.  Operational  Architecture  development  supports 
the  warfighter,  the  modeling  and  simulations  community,  the  training  community,  force  design 
decisions,  doctrinal  changes,  the  development  and  fielding  of  technology  enhancements/systems, 
software  development,  and  the  build  of  system  architectures. 


OA  provides  five  key  elements  to  the  base  line  of  TRADOC  Pam  71-9. 

OA  is  a  functional  blueprint  that  provides  a  disciplined  approach  to  the  requirement 
determination  process  (RDP),  and  is  the  cornerstone  for  the  RDP. 

OA  provides  the  functions,  information  requirements,  and  the  performance  parameters  that  a 
warfighter  needs  to  perform  his  mission.  The  ASA  community  to  develop  and  field  the  correct  type 
and  number  of  systems  to  enable  the  warfighter  to  execute  functional  requirements  uses  the  OA. 

OA  should  precede  the  development  of  system  architectures.  This  ensures  full  advantage  is 
taken  of  reengineering  potentials  identified  through  the  operational  architecture  process,  and  that 
technology  enhancements  are  analytic  based  and  represent  optimized  battlefield  return  on 
investment,  see  figure  6.  If  an  OA  is  not  produced  than  the  Warfighters  requirements  will  not  be 
defined  in  an  accurate  and  objective  manner  which  will  lead  to  misunderstanding  and  precious 
time  and  resources  will  be  miss-directed  or  incorrectly  used. 

OA’s  identify  and  document  new  and  emerging  operational  requirements  and  act  as  the  change 
catalyst  for  development  of  operational  capabilities  supporting  the  warfighter. 


The  OA  provides  the  functional  and  information  exchange  requirements  (IERs)  for  the  C4RDP. 
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Figure  6. 


The  OA  Products. 

Architecture  products  are  graphical,  textual,  and  tabular  items  developed  in  the  course  of 
building  an  operational  architecture  and  describe  characteristics  pertinent  to  the  architecture  and 
its  purpose.  The  set  of  operational  architecture  products  varies  depending  upon  the  type  of 
architecture  being  developed  and  its  specific  objectives  and  scope.  The  decision  of  which 
operational  architecture  products  to  build  is  based  on  the  area  the  architecture  is  intended  to 
explore  and  the  resulting  characteristics  that  the  architecture  must  capture  and  describe.  A  given 
architecture  may  consist  of  all  the  products  described  in  the  C4ISR  Architecture  Framework,  or 
it  may  be  a  selected  subset  of  those  products.  Templates  are  provided  for  developing  textual  and 
graphic  architectural  products.  The  relationship  among  the  architecture  products  facilitates 
traceability  of  solutions  back  to  the  operational  warfighter  support  requirements.  At  a  minimum 
the  following  products  are  required  in  every  OA  project. 

Overview  and  Summary  Information 
High-Level  Operational  Concept  Diagrams 
Command  Relationship  Charts 
Activity  Models 

Information  Exchange  Requirements 
Logical  Data  Models 
Integrated  Dictionary 
DTLOMS  Observations 

A  common  theme  among  these  products  is  the  information  flow  that  links  operational  elements 
and  the  activities  required  to  accomplish  operational  missions.  The  content  of  OA  products  is 
key  to  the  strategic  and  operational  vision  and  mission.  As  a  result,  the  level  of  detail  within 
each  product  will  vary  from  OA  to  OA. 

Each  product  and  the  characteristics  it  will  capture  are  addressed.  Additionally,  a  description  of 
how  the  product  can  be  used,  and  why  they  are  needed  is  provided.  Refer  to  the  C4ISR 
Architecture  Framework  and  the  AEA  Guide  Document  for  a  more  detailed  description  of  the 
products,  the  Integrated  Dictionary  Attributes  for  each  product,  and  how  the  products  relate  and 
support  the  development  of  the  Systems  Architecture  products. 

In  addition  to  these  products  there  are  other  supporting  OA  products.  Supporting  products  will  be 
developed  that  match  the  purpose  and  objectives  of  the  architecture  and  provide  data  needed  to 
build  the  essential  products.  Other  products,  found  in  one  or  more  references  (e.g.,  DoD,  C4ISR 
Architecture  Framework,  AEA  Guide  Document,  and  the  JTA-A),  may  be  required  to  ensure  that 
specific  architectures  are  complete  and  in  conformance  with  current  policy  and  formal  direction. 
The  supporting  OA  products  include. 

Node  Connectivity  Diagram 
Operational  Rules  Model 
Operational  State  Transition  Description 
Operational  Event/Trace  Description 


The  outcome  of  developing  an  OA,  is  the  total  aggregation  of  mission,  functions,  tasks, 
information  requirements,  and  business  rules,  is  a  set  of  products  that  provides  the  basis  for  the 
technical  and  system  architectures  as  well  as  the  information  to  review  or  redesign  the 
organization.  For  the  operational  architecture  product  types,  a  generic  "template"  is  shown  that 
illustrates  the  basic  format  of  the  product,  describes  the  characteristics  to  be  captured  in  the 
product,  and  lists  some  of  the  uses  of  the  product.  For  any  architecture  effort,  the  specific 
products  to  be  produced  and  the  level  of  detail  to  which  they  are  developed  depends  on  the 
purpose  of  the  architecture. 

The  Operational  Concept  Diagram.  These  diagrams  are  developed  in  two  parts.  The  first  is 
the  development  of  an  operational  concept  for  battle  deployment  of  the  unit  being  modeled.  The 
second  is  a  graphic  representation  or  depiction  of  that  concept.  While  the  graphic  representation 
depicts  the  concept  in  a  simple,  pictorial  form  (using  Microsoft  PowerPoint  software),  the 
operational  concept  must  define  how  the  concept  is  expected  to  support  the  warfighting 
requirement  and  enhance  command  and  control  across  the  battlefield.  The  operational  concept 
diagram  is  used  to  describe,  in  general  terms,  how  command  and  control  will  be  executed  for  the 
organization  to  be  modeled  and  provide  the  focus,  or  view,  against  which  the  modeling  and 
analysis  will  be  completed. 

Throughout  all  the  phases  of  architecture  development,  the  Operational  Concept  Diagram  serves 
as  the  single  picture  that  conveys  the  concept  of  the  fielded  architecture.  This  product  Shows  the 
“who,  what,  when,  where,  why,  and  how”  documented  in  the  Overview  and  Summary.  The 
Operational  Concept  Graphic  builds  on  the  information  used  in  creating  the  Overview  and 
Summary.  From  this  starting  point  assign  organizations  to  perform  each  activity.  The  original 
need  for  the  architecture  will  govern  the  level  of  detail  used  in  assigning  organizations.  For 
example,  if  the  purpose  of  the  architecture  was  to  refine  organizational  roles,  the  activities  and 
organizations  should  be  broken  down  into  enough  detail  to  show  one  organization  for  each 
activity. 

Once  the  data  have  been  organized,  build  the  first  Operational  Graphic.  Think  of  this  product  as 
a  graphic  summary  of  the  architecture.  Use  the  type  of  graphic  that  best  portrays  the  use  of  the 
architecture.  Like  the  Overview  and  Summary,  the  Operational  Concept  Diagram  information 
will  be  used  to  defend  budgetary  decisions,  and  to  track  and  guide  the  development  of  the 
architecture  at  all  levels. 

The  diagram  uses  generic  icons  that  represent  various  classes  of  entities  in  the  architecture  and 
can  be  tailored  as  needed  (e.g.,  a  tank  icon  can  represent  a  particular  type  vehicle,  a  particular 
armor  organization,  or  the  armor  assets  of  a  joint  task  force).  The  icons  represent  missions  or 
functions.  The  lines  connecting  the  icons  show  connectivity  information  exchanges.  How  the 
template  is  tailored  depends  on  the  scope  and  intent  of  the  architecture.  In  general  however,  an 
operational  concept  diagram  typically  shows  the  mission,  high-level  functions,  organizations, 
and  relative  distribution  of  assets. 

The  Command  Relationships  Chart,  is  used  to  show  the  operational  elements  involved  in  a 
particular  military  operation  and  the  relationships  among  them.  It  depicts  lines  of  command  and 
coordination  among  operational  elements  and  may  depict  operational  elements  either  in  generic 


terms  or  by  particular  organizational  element,  depending  on  the  particular  need.  The  level  of 
detail  to  be  shown  on  this  chart  is  commensurate  with  the  intended  use  of  the  architecture.  This 
type  of  chart  should  be  drawn  only  to  the  level  that  depicts  the  applicable  operational  elements 
and  lines  of  command. 

Command  relationships  illustrate  command,  control,  and  coordination  relationships  among 
operational  elements  in  an  organization.  For  example,  command  and  control  relationships  may 
differ  under  different  circumstances;  such  as  for  various  phases  of  warfare;  these  command 
structures  may  mean  that  activities  are  performed  differently  or  by  different  units.  Different 
coordination  relationships  may  change  connectivity  requirements. 

Activity  Modeling.  Activity  and  process  modeling  provide  a  description  of  the  activities  and 
functions  being  performed  at  each  level  within  the  structure(s)  being  modeled.  Additionally,  the 
process  models  provide  necessary  timing  data  and  information,  which  support  the  development 
of  dynamic  modeling  and  simulation.  These  models  are  developed  using  Integration  Definition 
(IDEFO)  language  (for  Function  Modeling)  with  standard  IDEF  conventions  and  notations.  The 
IDEFO  activity  models  are  in  compliance  with  the  Federal  Information  Processing  Standards 
Publications  (FIPS)  183.  The  activity  (IDEFO)  and  process  (IDEF3)  models  provide  the 
identification  of  functions/activities  performed,  associated  processes,  and  information  relative  to 
information  flow  and  IERs.  The  results  of  these  modeling  activities  provide  the  basis  from 
which  to  execute  further  dynamic  modeling  and  simulations  and  conduct  refined  analytic 
analysis  and  assessments.  These  are  the  basis  upon  which  business  process  reengineering  (BPR) 
recommendations  are  made  and  the  future  or  “to-be”  OA’s  are  developed.  BPR  is  a  method  for 
looking  at  the  current  function  of  an  element,  and  determining  if  a  better  alternative  s  available  to 
enhance  future  functional  efficiencies.  Utilization  of  this  modeling  software  and  techniques 
provide  a  disciplined  approach  to  data/information  capture,  documentation,  standardization  of 
definitions/terms,  and  a  thorough  understanding  and  description  of  the  activities  associated  with 
specific  nodes.  These  IDEF  models  provide  the  detailed  information  relative  to  managing  needs 
and  functional  analysis,  requirement  definition,  and  IERs  from  which  additional  OA  products  are 
developed. 

The  Activity  Model  describes  the  applicable  activities  associated  with  the  architecture,  the  data 
and/or  information  exchanged  between  activities,  and  the  data  and/or  information  exchanged 
with  other  activities  that  are  outside  the  scope  of  the  model  (i.e.,  external  exchanges).  Activity 
models  are  hierarchical  in  nature;  that  is,  they  begin  with  a  single  box  that  represents  the  overall 
function  and  proceed  successively  to  decompose  processes  into  activities  to  the  level  required  by 
the  purpose  of  the  architecture.  This  is  analogous  to  a  work  breakdown  structure  for  a  system. 

Using  the  IDEF  process  the  Activity  Model  captures  the  activities  performed  in  a  business 
process  or  mission  and  their  ICOMs  (Inputs,  Controls,  Outputs,  and  Mechanisms).  Mechanisms 
perform  an  activity,  usually  a  person,  duty  position,  or  work  cell  within  an  organization.  Inputs 
are  things  changed  or  used  in  the  activity,  usually  information,  a  decision,  or  a  sensor  feed. 
Controls  are  the  rules  that  govern  the  activity,  this  can  be  in  the  form  of  higher’s  orders,  and 
regulations.  And  outputs  are  what  leave  the  activity;  examples  are  annexes,  orders,  decision,  or 
information.  Annotations  to  the  model  may  identify  the  nodes  where  the  activities  take  place  or 
the  costs  (actual  or  estimated)  associated  with  performing  each  activity. 


The  Activity  Model  can  capture  valuable  information  about  an  organization.  However,  care 
must  be  taken  to  not  collect  extraneous  information.  There  are  two  modeling  approaches; 
generic  and  detailed.  The  generic  model  approach  is  to  specify  the  activities,  generic  ICOM 
categories,  and  specific  characteristics  to  be  captured  in  the  models.  The  objective  of  this 
technique  is  to  focus  the  modeling  effort  so  that  a  number  of  small,  quickly  developed  activity 
models  can  be  produced  instead  of  a  large,  many-layered  model.  However,  the  resolution  in  the 
decomposition  of  functions  may  not  be  to  sufficient  detail.  The  detailed  model  approach 
specifies  the  activities  in  greater  details,  decomposing  functions  to  the  node  level.  Node  level  is 
defined  as  the  lowest  level  that  a  function  is  performed  which  requires  information  to  perform 
that  function,  or  a  function,  which  produces  information.  TPIO-ABCS  has  developed  a  generic 
Army  Common  Activity  Model  (ACAM)  which  will  serve  as  a  basis  for  building  the  various 
other  activity  models. 

The  Activity  Model  generally  includes  a  chart  of  the  hierarchy  of  activities  covered  in  the  model, 
facing-page  text  for  each  diagram  that  provides  any  required  detail,  and  a  dictionary  that  defines 
all  activities  and  terms  used  in  the  diagrams.  The  Integrated  Dictionary  product  serves  as  this 
dictionary.  The  applicable  activities  associated  with  specific  functions  and  processes  that  must  be 
accomplished  to  support  a  particular  mission,  the  relationship  among  activities,  the  data  or 
information  exchanged  between  activities  and  the  data  or  information  exchanged  with  other 
activities  that  are  outside  the  scope  of  the  model. 

Information  Exchange  Requirements  (IER)  Matrix.  This  matrix  identifies  the  connectivity 
between  the  various  operational  elements  at  the  leaf  node  level  and  provides  the  performance 
parameters  associated  with  leaf  node  information  requirements  (inputs  and  outputs).  The 
operational  element  connectivity  will  be  shown  as  information  exchanges  between  a  producer 
(normally  one  person)  and  various  users.  This  information  and  the  definitions  provided  with  the 
activity  model  are  of  major  importance  to  the  Systems  Architects.  Through  the  development  of 
the  IER  matrix,  current  information  requirements  (IR’s)  and  IER’s  within  the  C4RDP  will  be 
validated  as  well  as  identification  and  creation  of  new  IR’s,  IER’s,  and  OPFAC  rules  which  will 
be  feed  into  the  C4RDP  data  base.  The  SIGCEN  oversees  the  management  of  the  C4RDP 
database. 

The  IER  matrix  expresses  the  relationship  across  the  three  basic  entities  (tasks,  operational 
elements,  and  information  flow)  in  an  OA.  The  IER  is  defined  as  the  requirement  for 
information  to  be  passed  between  and  among  forces,  organizations,  or  administrative  structures 
concerning  ongoing  activities.  IERs  identify  who  exchanges  what  information  with  whom,  why 
the  information  is  necessary,  and  in  what  manner  the  exchange  takes  place.  IERs  identify  the 
elements  of  warfighter  information  used  in  support  of  a  particular  activity  and  between  any  two 
activities.  The  information  media  (e.g.,  data,  voice,  and  video),  quality  (e.g.,  frequency, 
timeliness,  and  security),  and  quantity  (e.g.,  volume  and  speed)  are  attributes  of  the  information 
exchange  that  may  be  included  in  the  IER.  Particular  capabilities  such  as  automated  data 
processing  capabilities,  secure  communications,  facsimile,  database  query,  and  large-screen 
display  may  also  be  captured  for  each  exchange.  Required  capabilities  may  be  extended  to 
capture  other  needs  such  as  personnel  skills  or  facilities.  The  specific  attributes  used  to  describe 
the  information  exchange  are  driven  by  the  purpose  for  which  the  architecture  is  being 
developed. 


Logical  Data  Modeling.  IDEF1X  data  modeling  supports  the  IRs  identified  in  the  activity 
model,  and  describes  in  detail  the  information  entities,  attributes,  and  entity  relationships.  DoD 
manual  8320.1-M-l  and  FIPS  183  and  184  require  all  data  models  to  be  activity  model  based. 
Prior  to  the  execution  of  data  models,  the  C2  Core  Data  Model  (C2CDM)  will  be  queried  to 
ensure  no  duplication  of  effort  will  exist  and  that  all  data  models  to  be  developed  are  valid 
extensions  to  the  C2CDM.  Additionally,  the  C4ISR  Core  Architecture  Data  Model  (CADM)  and 
the  Joint  Transition  Data  Model  (JTDM),  will  also  be  queried  to  ensure  maximum  optimization 
of  work  already  performed/completed  is  taken  advantage  of.  The  development  of  data 
models/extensions  provides  the  necessary  resolution  of  information/data  to  the  material 
developer,  systems  engineer,  and  software  developer  to  develop  systems  and  software  in  an 
optimal  manner.  The  TRADOC  Systems  Managers  for  respective  systems  must  be  a  part  of  this 
process  and  support  the  development  of  data  models  for  their  systems.  All  data  modeling 
initiatives  being  conducted  in  support  of  TRADOC  systems  will  be  coordinated  with  the 
Commanding  General,  Combined  Arms  Center  (TPIO-ABCS  as  the  USACAC  lead).  TPIO- 
ABCS  will  validate  the  requirement,  coordinate  execution  with  Headquarters,  TRADOC  (as 
necessary),  and  ensure  the  data  modeling  approach  is  consistent  and  complementary  to 
development  of  the  Operational  Architecture  initiatives.  Currently  Platinum  software  ERwin  is 
FIPS  184  compliant  and  it  will  be  used  to  perform  the  IDEF1X  data  modeling. 

Integrated  Dictionary.  The  Integrated  Dictionary  contains  definitions  of  all  significant  terms 
used  in  the  products.  It  is  not  assigned  to  any  one  architecture  type  because  it  supports  and  is 
populated  by  all  three  architectures  (operational,  systems,  and  technical).  Similarly,  the  data 
model  is  not  assigned  to  any  one  type  of  architecture.  However,  the  data  dictionary  and  the  data 
model  development  should  begin  in  parallel  with  the  development  of  the  OA. 

This  is  also  a  DoD  essential  product.  At  a  minimum,  the  Integrated  Dictionary  is  a  glossary  with 
definitions  of  terms  used  in  the  given  architecture  description.  There  must  be  definitions  and  data 
associated  with  these  essential  products.  The  Integrated  Dictionary  provides  a  central  source  for 
this  information.  The  Integrated  Dictionary  makes  the  set  of  architecture  products  stand-alone 
and  allows  it  to  be  read  and  understood  without  reference  to  other  documents. 

The  contents  for  the  Integrated  Dictionary  entries  for  the  OA  products  are  evolving.  Refer  to  the 
Attribute  Tables  provided  for  architecture  products  in  Appendix  A  to  C4ISR  Architecture 
Framework ,  Version  2.0  for  instructions  to  produce  the  Integrated  Dictionary.  These  attributes 
are  consistent  with  the  CADM  for  the  architecture  products.  An  architecture’s  Integrated 
Dictionary  product  contains  the  specific  values  of  the  data,  while  the  CADM  describes  the  types 
and  relationships  of  these  data. 

The  C4ISR  Architecture  Framework,  Version  2.0,  directs  that  architects  should  use  terms  from 
existing,  approved  dictionaries  and  lexicons.  All  definitions  from  existing  dictionaries  should 
provide  a  reference  to  show  the  source.  At  times,  however,  new  terms  and/or  modified 
definitions  of  existing  terms  will  be  needed.  This  can  happen  when  a  given  architecture  is  at  a 
different  level  of  detail  than  existing  architectures  or  lexicons,  or  when  new  concepts  are  devised 
for  objective  architectures.  In  those  cases,  the  new  terms  should  be  submitted  to  the  maintainer 
of  the  approved  dictionaries. 


The  dictionary  is  a  compilation  of  dictionary  entries  for  each  product  generated  by  the 
architecture.  The  dictionary  begins  with  the  entries  about  the  first  version  of  the  Overview  and 
Summary  Information.  The  final  version  of  the  integrated  dictionary  will  be  done  when  the  last 
product  is  produced  and  its  entries  included.  To  prevent  confusion  within  and  across 
architectures,  care  must  be  taken  to  avoid  duplication  of  names  or  descriptions  without  proper 
reference  to  their  origin. 

Conduct  Analysis.  After  the  OA  is  developed,  it  can  be  analyzed  to  define  an  organization,  to 
reevaluate  an  existing  organization,  develop  a  system  or  process,  or  assess  the  impact  on  the 
DTLOMS  domains. 

IDEF  models  are  used  to  develop  BPR  recommendations  and  changes  to  DTLOMS  domains. 
BPR  is  a  method  for  looking  at  the  current  function  of  an  element,  and  determining  if  a  better 
alternative  is  available  to  enhance  future  functional  efficiencies.  The  activity/process  models  are 
utilized  by  the  modeling  and  simulations  community,  such  as  the  TRADOC  Analysis  Command 
(TRAC),  the  National  Simulations  Center  (NSC),  the  Army  Systems  Architect  in  the 
development  of  systems  architectures,  software  engineers  and  designers  to  gain  a  greater 
understanding  of  the  functions/activities  the  software  must  support,  doctrine  writers  to  write 
emerging  concepts  and  doctrine,  the  warfighter  to  assess  where  efficiencies  may  be  gained  in 
either  their  force  structure  or  conduct  of  operations,  and  the  training  community  in  the 
development  of  training  support  plans  (TSP’s)  and  development  of  new  training  tasks.  The 
results  of  the  data/information  collection  and  IDEF  modeling  also  populate  numerous  databases, 
such  as  the  Enterprise  Architecture  database  (vis-a-vis  the  C4RDP),  the  DISA  C2CDM,  the 
Army  Common  DataBase  (ACDB),  and  the  CADM.  The  OA  may  be  used  to  develop  or  validate 
an  organizational  structure,  and  it  may  also  be  used  to  develop  a  systems  architecture.  A 
discussion  on  how  the  OA  is  used  to  develop  the  systems  architecture  is  presented  at  in  the 
C4ISR  Architecture  Framework. 

During  the  development  of  the  OA,  DTLOMS  impacts,  insights,  and  analysis  produce 
observations.  These  observations  are  listed  in  matrix  form  (Access  database).  The  OA  and  the 
follow-on  analyses  document  the  impact  across  the  DTLOMS.  Through  business  process 
reengineering  methodologies  efficiencies  are  optimized,  redundancies  eliminated,  and  ‘what  if’ 
analysis  performed  (Figure  A-26). 

The  OA  has  a  number  of  characteristics  that  make  it  useful  as  a  tool  for  developing  and 
validating  organizational  structures.  They  are  itemized  below: 

The  OA  embraces  the  range  of  potential  environmental  conditions  such  that  the  resulting 
architecture  is  generic  and  is  insensitive  to  any  specific  environment  (physical,  military,  and 
civilian). 

The  OA  identifies  and  defines  the  principal  components  in  the  operational  scenarios  and  general 
nature  of  the  information  elements  that  need  to  be  exchanged. 

The  OA  encompasses  the  operational  influences  of  doctrine,  policy,  tactics,  techniques,  and 
procedures. 


The  OA  identifies  existing  constraints  (i.e.,  manpower,  logistics,  training,  and  funding). 

Configuration  Management. 

The  purpose  of  Configuration  Management  (CM)  is  to  establish  an  orderly  method  of  control 
over  the  configured  baseline  OA  products.  The  major  elements  of  the  configuration  management 
concept  are  shown  in  Figure  5.  A  complete  description  of  the  OA  CM  is  contained  in  the  TPIO- 
ABCS  Configuration  Management  Plan  (CMP)  for  the  AOA.  The  TPIO-ABCS  CM  Plan  is 
posted  on  the  OA  web  site.  The  specified  procedures  provide: 

A  means  for  requested  changes  to  be  initiated,  reviewed,  approved,  prioritized,  and  implemented. 
A  means  to  track  the  implementation  of  changes  made  to  the  OA  product  set  and  repositories 
through  a  configuration  control  process. 

A  means  for  issues  to  be  identified,  reviewed,  and  resolved  or  put  into  the  change  process. 

No  changes  to  the  OA  products  will  be  implemented  unless  it  is  authorized  and  approved  by  the 
Configuration  Control  Board  (CCB)  and  verified  and  validated  by  the  CM  process,  see  Figure  7. 
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Figure  7. 


OA  Laboratory  and  Integration  Center. 

The  TRADOC  Operational  Architecture  Laboratory  and  Integration  Center  is  located  within  the 
TPIO-ABCS.  Its  purpose  is  to  provide  the  capability  to  conduct  dynamic  modeling  and 
simulation,  support  the  assessment  and  development  of  recommended  changes  to  the  DTLOMS, 
provide  the  ability  to  merge  and  integrate  various  activity /process  models  and  data  models,  and 
provide  configuration  control  and  management  of  all  OA  activities  within  TRADOC.  Access  to 
the  OA  lab  is  through  a  server  administered  by  TPIO-ABCS  OA  Branch.  The  OA  products  and 
models  will  be  available  to  view  and  pull  down. 


AQA  Repository. 

TPIO-ABCS  will  maintain  the  Army's  OA  repository.  After  an  OA  is  completed,  and  accepted 
by  the  OA  CCB,  it  will  reside  in  the  OA  repository.  TPIO-ABCS  will  control  access  to  the 
repository.  The  OA  products  and  models  will  be  available  to  view  and  retrieve.  This  is  essential 
in  order  to  maximize  product  reuse,  thereby  creating  efficiencies  and  saving  resources.  Any 
agency  conducting  an  OA  must  review  the  products  in  the  repository  to  evaluate  the  reuse 
potential.  Contact  TPIO-ABCS  OA  personnel  for  recommendations  of  which  models  will 
provide  the  most  reuse  value. 

The  AOA  provides  the  functional  and  IERs  for  the  C4RDP.  OA  products  will  not  be  provided  to 
the  C4RDP  until  it  is  approved  by  the  TPIO-ABCS  OA.  The  TPIO-ABCS  OA  and  C4RDP  will 
work  together  to  ensure  any  detected  anomalies  are  reported  to  the  OA  CCB  for  resolution. 

Measurements. 

TPIO-ABCS  OA  must  collect  data  that  focuses  on  criteria  that  evaluates  the  cost  factors  of 
implementing  OA,  identified  analytical  issues,  and  potential  impacts.  These  factors  fall  into 
three  basic  categories;  performance,  analytical  results,  and  risk  management.  Because  of  their 
potential  magnitude,  all  three  data  collection  areas  are  critical  to  the  success  of  the  OA  program. 

Performance  Measures. 

The  Army  must  measure  performance  to  determine  the  degree  of  how  to  use  its  resources 
effectively  and  efficiently.  The  Chief  of  Staff  of  the  Army  has  determined  that  increased  return 
on  investment  will  be  a  key  criterion  for  performance  measurement.  To  implement  this 
requirement,  TPIO-ABCS  will  collect  data  gathered  in  each  of  the  OA  Life  Cycle  phases.  The 
data  will  focus  in  two  main  areas:  internal  and  external.  Internally,  the  OA  staff  must  collect 
data  on  expended  man-hours,  funds,  and  resources  to  implement  OA.  Externally,  data  must  be 
collected  on  how  the  implementation  of  OA  has  provided  cost  savings  and  reduced  risks.  OA 
performance  measures  provide  the  focus  and  structure  required  to  support  the  disciplined 
approach  that  OA  brings  to  the  Requirements  Determination  Process. 

Analysis  Results.  Issues  and  observations  are  discovered  during  each  of  the  OA  Life  Cycle 
phases.  This  data  can  include  issues  related  to  resources,  doctrine,  training,  reports,  manpower, 
or  DTLOMS  criteria.  These  findings  will  be  submitted  to  TPIO-ABCS.  In  turn,  TPIO-ABCS 
will  evaluate  these  findings  and  forward  them  to  either  the  AOA  CCB  or  appropriate  agency  for 
consideration.  Pending  the  findings,  it  is  possible  that  this  data  can  also  be  considered 
performance  measure  criteria  or  a  risk  factor. 

Risk  Management.  A  risk  is  defined  as  a  factor,  an  element,  or  a  requirement  that  has  the 
potential  to  cause  a  problem  or  impact.  During  each  phase  of  the  OA  Life  Cycle,  numerous  risks 
can  surface  which  could  turn  into  potential  problems  for  the  program.  To  ensure  that  these 
problems  are  identified  and  properly  controlled,  the  CCB  will  be  the  mediator  for  risk 
management.  The  goal  is  to  identify,  track,  manage,  and  resolve  each  identified  risk  so  that  it 
does  not  reach  an  uncontrollable  state. 

OA  Web  Page.  TPIO-ABCS  OA  Branch  will  maintain  an  OA  web  page  (http://leav- 
www.army.mil/oa/)  that  will  notify  users  of  the  latest  AOA  information.  This  will  include  the 


AOA  Implementation  Plan,  OA  products,  OA  Tool  Box,  Product  Change  Request  (PCR)  status, 
information  on  the  repository,  the  CMP,  the  CCB  Charter,  and  updates  on  the  AOA  program. 


Tools.  Currently,  TPIO-ABCS  is  utilizing  Platinum  BPwin  for  activity  modeling  (IDEFO) 
development,  ERwin  for  data  modeling  (IDEF1X)  development,  and  Model  Mart  for 
configuration  management  of  the  models.  BPwin  and  ERwin  are  in  compliance  with  the  Federal 
Information  Process  Standards  (FIPS)  and  DoD  8320.1-M-l  directives.  Microsoft  Access  data 
base  software  is  used  to  produce  the  IER  matrices. 

Configuration  Control  Management  (CCM).  Configuration  control  management  will  be 
performed  IAW  the  TPIO-ABCS  Configuration  Control  Management  Plan  for  the  Army 
Operational  Architecture  (AOA).  The  AOA  CCB  will  operate  IAW  the  TPIO-ABCS  Army 
Operational  Architecture  (AOA)  CCB. 

AOA  PROGRAM  SUMMARY 


The  Army’s  Operational  Architecture  codifies  the  Warfighter’s  functional  requirements  across 
the  battlefield.  It  serves  as  the  foundation  for  all  DTFOMS  development  and  provides  a 
disciplined/analytic  approach  to  change  recommendations  across  the  DTFOMS.  It  serves  as  a 
mechanism/tool  supporting  cost  containment  strategies.  AOA  captures/develops  future  C4I 
requirements  and  is  the  basic  tenet  of  Army’s  Requirements  Determination  Process.  Most 
importantly  AOA  serves  as  a  catalyst  for  Business  Process  Re-engineering  of  the  Army  of  today 
and  the  future. 


